Shared memory is usually employed when multiple processors exchange messages. That is, when a first processor (which we herein term “CPU”) writes a message into the shared memory so that a second processor (which we herein term “COP”) can then read the message from the shared memory. Maintaining the integrity of the messages thus exchanged requires that any updating of the content of the message be performed “atomically” with respect to the software threads of execution.
Multiple processor safe message queues are typically implemented using such shared memory, as well as with locks and asynchronous signaling. The messages are put in the shared memory, and then read and written only after certain precautions are taken. For instance, the reader or writer software thread that creates the message will acquire a multi processor safe lock (usually implemented using a “spin lock”). And, when necessary, it will also acquire a single processor multi thread safe lock (usually termed a mutual exclusion lock or “mutex”).
FIGS. 1a-c are schematic block diagrams wherein FIG. 1a stylistically depicts the general hardware (HW) environment of interest and FIGS. 1b-c depict the regular software (SW) operations necessary in prior art schemes.
There are usually also a few “corner conditions” that need to be considered. For instance, one needs to deal with the special case when a read is attempted but the message queue is empty, and one also needs to deal with the special case when a write is attempted but the message queue is full. Asynchronous signaling is typically used to handle these conditions (e.g., signaling after the first write to an empty message queue to wake up a waiting reader thread). Such asynchronous signaling is usually implemented by one processor interrupting another, and then within an interrupt service routine (ISR) signaling with a semaphore to wake up the blocked thread.
Unfortunately, all of these locking and signaling mechanisms require significant software design and implementation effort and significant runtime overhead.
Let us consider an example based on a spin lock. If a first thread running on CPU (a first processor) has acquired the spin lock and is preempted by another thread on CPU (the first processor), and then a third thread on the COP (the second processor) tries to get the spin lock it will be blocked for a long time until the first threads becomes active again and then releases the spin lock. Spin locks are usually implemented as polling within a loop that runs forever until the condition is met. As can be appreciated, this scheme may result in a temporary priority inversion, wherein a very high priority task on COP is delayed because a lower priority thread on CPU has ownership which is preempted by an unrelated higher priority thread on CPU. This scheme can also easily cause significant wait time, wherein COP becomes essentially useless while waiting on a favorable polling result.
Which has ownership is preempted by an unrelated higher priority thread on CPU.
Similarly, the use of a mutex imposes another overhead. Some operating systems (OSes) and real time OSes (RTOSes) take a significant amount of time to acquire a mutex even when the resource it is protecting is available.
Accordingly, what is still needed is a more efficient system for multiple processors to exchanges messages. This system should preferably eliminate the need to employ software-based mechanisms such as the spin lock and the mutual exclusion lock (mutex).